Release date: 13 October 2004 (interim release)
Polymost uses the Quake II MD2 model format for 3D models. You can replace any wall-aligned or face sprite in the game with a 3D model using a declaration in the DUKE3D.DEF file. For more information on the specifics of the DEF-file commands for 3D models, see here.
Included in this release is a model of the Pig Cop by Parkar, and the skin by Motionblur. Visit this thread on the 3D Realms forum for more model information. I shall use this model to demonstrate how to replace the Pig Cop character in Duke.
Here is the definition for the pig cop which is also included in the sample DUKE3D.DEF file.
definemodel "models/pigcop.md2" 1.30 0 definemodelskin 0 "models/pigcop.jpg" definemodelanim "walk0" "walk13" 20 0 definemodelframe "walk0" 2000 2019 definemodelanim "pump0" "pump2" 10 1 definemodelframe "pump0" 2025 2027 definemodelframe "stand" 2030 2034 definemodelanim "shoot0" "shoot2" 10 1 definemodelframe "shoot0" 2035 2037 definemodelanim "dive0" "dive3" 8 1 definemodelframe "dive0" 2040 2044 definemodelframe "dive3" 2045 2049 definemodelanim "dshoot0" "dshoot2" 10 1 definemodelframe "dshoot0" 2050 2052 definemodelframe "die0" 2055 2055 definemodelanim "die1" "dead" 13 1 definemodelframe "die1" 2056 2059 definemodelframe "dead" 2060 2060
Without going through every line of the example, here is the basis of how the definitions work. You must put a definemodel line before any other definemodelframe or definemodelanim lines. The frame and anim lines refer the the definemodel line which precedes them. You can define frames and animations in any order, ie. the animations do not need to be given before the frames, but it is a good convention to keep them together for clarity.
The walking loop for the pig cop spans tiles 2000 to 2019. The model contains a fourteen frame walking animation which we play at 20 frames per second. The first line of the example specifies the "models/pigcop.md2" model should be drawn at 1.3 times its normal scale and be left undarkened or lightened. The definemodelskin line specifies the skin to use for palette 0 for all the definemodelframe lines that follow it. The first of the definemodelanim lines declares the fourteen frame walking animation at 20fps which should loop (the 0 for the flags parameter says to loop). The definemodelframe line which follows it maps the ART tiles from 2000 through to 2019 to play the walking animation. Because the name in the definemodelframe line matches the first frame of the definemodelanim line, the animation will automatically play.
Quake II is a registered trademark of id Software
These are the legal instructions that may be used in the DUKE3D.DEF file. Comments can be used by
prefixing the text with a double forward-slash (C++ style), //, or surrounding the text with
/* (comment here) */ (C style).
Whenever a numeric value is required, it can be specified in three bases: decimal (base 10), hexadecimal (base 16), and octal (base 8). Decimal numbers are obvious, but don't use extra leading zeroes to pad a decimal number to a particular width. A leading zero on a number indicates it is an octal number. To give a number in hexadecimal, use a '0x' prefix. These all represent the same number: 16 (decimal) = 020 (octal) = 0x10 (hexadecimal)
Ken has some utilities on his website that can assist you in converting your favourite skybox format to Polymost format. (http://advsys.net/ken/kube/kube.htm) If your skybox is in Mercator projection, then you'll need to run MERC2KUB.EXE first. Once you have your 6 face textures, you can use KUBE.EXE to convert it to Polymost format using the /split option. The face textures can be in almost any configuration - KUBE has fancy autodetection code. For example, typing "kube globe.mov /split" will generate the 6 face textures in the order and orientation that Polymost expects. The output files will be called SPLITCAP0.PNG, SPLITCAP1.PNG, ..., SPLITCAP5.PNG. After conversion, I suggest you rename the files and compress them using PNGOUT or similar utility.
"Map Hack" scripts are files that override certain aspects of a map file when it is rendered in OpenGL Polymost mode. Currently they allow for angle adjustment on sprites, and the ability to prevent particular sprites from being drawn as a model. These are useful for making small corrections to ornamental sprites in a way that doesn't require modifying the original map.
The game will automatically load a map hack script whenever a map is loaded. The script should have the same base name as the original .MAP file, but with an .MHK extension. The map hack language is described below. It uses the same parser as DEF files, so you can use comments in the same way.
Here is an example map hack script:
// Map hack file for JFDuke3D // Level: E1L2.MAP (Original Atomic Edition version) // Prepared by jonof@edgenetwork.org // Invisible switch behind hand dryer in toilet of porn shop sprite 191 notmd2 // Invisible switches on telephones near billiards room in club sprite 254 notmd2 sprite 517 notmd2 // Toilet in restroom in club sprite 478 angoff -512
This release features the "Hightile" texturing improvements to Polymost. Hightile allows Polymost to use true-colour textures instead of the artwork in the game's usual .ART file.
Replacement textures can be saved as JPEG, PNG (alpha channel supported), TGA, BMP, CEL, GIF, and PCX formats. Hightile uses Ken Silverman's picture library to provide rapid picture file loading.
Hightile textures are defined in the DUKE3D.DEF file. See the DEF-file language reference for information on how to specify Hightile textures.
Duke (and Build games in general) can load game resources from a ZIP file.
ZIP files are used in Duke in the same manner as extra GRP files are specified. Use the "/g" command-line
switch to specify the ZIP to load. eg. DUKE3D.EXE /gMYFILE.ZIP
Polymost is a full 3D implementation of the Build engine renderer, with hardware acceleration capability, and perspective in six degrees of freedom. In Ken's own words (copied from POLYMOST.C in my Build engine source distribution):
"POLYMOST" code written by Ken Silverman
Ken Silverman's official web site: http://www.advsys.net/ken
Motivation:
When 3D Realms released the Duke Nukem 3D source code, I thought somebody would do a OpenGL or
Direct3D port. Well, after a few months passed, I saw no sign of somebody working on a true
hardware-accelerated port of Build, just people saying it wasn't possible. Eventually, I realized
the only way this was going to happen was for me to do it myself. First, I needed to port Build to
Windows. I could have done it myself, but instead I thought I'd ask my Australian buddy, Jonathon
Fowler, if he would upgrade his Windows port to my favorite compiler (MSVC) - which he did. Once
that was done, I was ready to start the "POLYMOST" project.
About:
This source file is basically a complete rewrite of the entire rendering part of the Build engine.
There are small pieces in ENGINE.C to activate this code, and other minor hacks in other source
files, but most of it is in here. If you're looking for polymost-related code in the other source
files, you should find most of them by searching for either "polymost" or "rendmode". Speaking of
rendmode, there are now 4 rendering modes in Build:
rendmode 0: The original code I wrote from 1993-1997
rendmode 1: Solid-color rendering: my debug code before I did texture mapping
rendmode 2: Software rendering before I started the OpenGL code (Note: this is just a quick
hack to make testing easier - it's not optimized to my usual standards!)
rendmode 3: The OpenGL code
The original Build engine did hidden surface removal by using a vertical span buffer on the tops
and bottoms of walls. This worked nice back in the day, but it it's not suitable for a polygon
engine. So I decided to write a brand new hidden surface removal algorithm - using the same idea
as the original Build - but one that worked with vectors instead of already rasterized data.
Polymost is the default renderer choice for any video mode with a colour depth greater than 256 colours.
NOTE: If your computer does not have an OpenGL graphics card, Polymost in OpenGL mode will most likely use the default Windows OpenGL rasterising facility which does all rendering in software. This may be extremely slow. If your Windows installation doesn't have any form of OpenGL rendering ability, Polymost will probably crash.
NOTE 2: OpenGL Polymost has been tested on an nVidia Riva TNT 16MB, an nVidia GeForce2 GTS 32MB, an nVidia GeForce4 Ti4600 128MB, an ATi Radeon Mobility 9000 64MB, and a 3D-Labs Oxygen GVX420 128MB (minor texturing issues).
This is a list of console commands and variables and their purpose:
The content in this section is here for historical reference purposes.
This information is here for reference only. The networking feature is currently under redevelopment. Although the code in this release works, it fails with more than two players trying to join.
Because this feature is still experimental, setting up a network game is not the most streamlined of tasks, but it is achievable. First, some things to note:
So, knowing these particular nuances, this is how to configure a network game.
IMPORTANT: Place two or more blank lines at the end of the configuration files below or the game will start in single-player mode. This is a bug in my script loading code which I have not yet fixed.
A machine hosting a game needs to create a configuration file which contains the following information:
This can be placed in a text file (which for this demonstration I will name player-host.ini) like so:
[Network Game] IPPort = 19014 Mode = "Host" Players = 2
To then start the game and wait for players to join, either create a shortcut to DUKE3D.EXE and modify its properties to use a command line like the following, or type the following at a DOS prompt.
D:\Duke3D> duke3d.exe -net player-host.ini -name JonoF
The game will then start and wait for players to join.
A machine joining a game needs to create a configuration file which contains the following information:
This can be placed in a text file (which for this demonstration I will name player-join.ini) like so:
[Network Game] IPPort = 19014 Mode = "Join" Host = "asuka:19014"
To then start the game and wait until the rest of the players join, either create a shortcut to DUKE3D.EXE and modify its properties to use a command line like the following, or type the following at a DOS prompt.
D:\Duke3D> duke3d.exe -net player-join.ini -name FonoJ
The game will then start and wait until enough players have joined.
Before I explain the new 3D model support, I need to explain the changes which have been made to how the Hightile enhancements, 3D models, and voxels are described to the game.
Users of previous releases of the port would be familiar with the "definetexture" instruction in the CON language which is used to declare Hightile replacement textures. Typically, you would have an extra CON file, often named EXTRA.CON, which you would use to declare textures and whatnot. This file would be passed to the game using a "/x" switch to override the default GAME.CON from executing. In order to provide more generic flexibility so that the enhancements are not tied to the CON language, I have created a new script loader as a service of the engine which is now used to read a file containing those same definitions which CONs once provided. This script file is named DUKE3D.DEF and its syntax is similar to the CON language.
The benefits to come from this change to a separate file arrangement is that the new engine features now work in the Build editor as well as the game. Plus, the script reader is a reusable component of the engine which means any future games, or any modifications based on the engine will have the option of using this feature for themselves.
Since the port now uses the DUKE3D.DEF file to specify replacements and whatnot, the CON features have been disabled and a warning written to the console put in their place, something like:
!!! BEGIN NOTICE !!! CON-file definition of Hightile textures has been removed in favour of DUKE3D.DEF declarations. Please refer to the release notes for details on how to convert your CON definitions into DUKE3D.DEF equivalents. !!! END NOTICE !!!
Since DUKE3D.DEF has a syntax much like the CON language, conversion is not a difficult task. Refer below to the details on the instructions and their parameters for specifics, but here is the basic changes which you would need to make to an EXTRA.CON file to create DUKE3D.DEF:
Complete reference on the DUKE3D.DEF file is here.
Happy Duke'ing!